![]() |
The gDEBugger ôPerformance Analysisö toolbar offers tools that enable you to identify your applicationÆs graphic pipeline bottlenecks.
If performance improves after turning off a certain stage, you have found a graphic pipeline bottleneck.
The profiling mode removes CPU intensive logging operations performed by the gDEBugger OpenGL implementation. Such operations include "Textures Data Logging" and "OpenGL Calls History Logging".
The Collected Profiling graph data can be saved in a file (.csv) using this button or from the File menu.
Saving the data in a file enables you to run performance and regression tests for your application using different hardware and driver configurations or to compare the performance of two versions of your application.
The following toolbar commands enables ôTurning offö graphic pipeline stages:
This command causes the gDEBugger OpenGL implementation to ignore all OpenGL function calls that push primitives or raster data into OpenGL (glVertexXX, glDrawElements, glDrawPixels, etc). When this command is on, the CPU execution and bus transactions are active. However, most GPU actions are inactive since they are activated per primitive/ raster data.
This command helps identify CPU and bus transactions bottlenecks. If when eliminating all draw commands, application performance does not improve significantly, then your application is CPU or bus transactions limited.
This command forces the gDEBugger OpenGL implementation to use a 1X1 pixels view port instead of the application-defined view port.
OpenGL raster operations are triggered per fragment / pixel. Forcing OpenGL to use a single pixel view port removes most the executions performed by raster operations. Consequently, using the ôForce Single Pixel View Portö command enables the identification of raster operation related bottlenecks. If when forcing a single pixel view port, application performance improves, then your application is raster operations limited.
This command forces the gDEBugger OpenGL implementation to render using no lights instead of the application-defined lights. This command enables the identification of lights related computations performance bottlenecks. If when forcing the render using no lights, application performance improves, then your application is lights related computations limited.
This command forces the gDEBugger OpenGL implementation to use a 2X1 (1D), 2X2 (2D), 2X2X2 (3D) and 2X2 x 6 (cube map) textures instead of the application-defined textures. Forcing the use of such small textures guarantees that the textures data constantly remains in the textures memory cache. Texture cache fetch operations occur when the used textures data does not reside in the textures cache and, consequently, must be fetched into it. Using the ôForce Stub Texturesö command enables the identification of texture cache fetch performance bottlenecks. If when forcing stub textures, application performance improves, then your application is texture data fetch limited.
This command forces the gDEBugger OpenGL implementation to use a very simple fragment shader instead of the application-defined fragment shader. This command enables the identification of fragment shader related performance bottlenecks. If when forcing the use of a stub fragment shader, application performance improves, then your application is fragment shader limited.